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REMARKS/ARGUMENTS 

The above-referenced application was filed on May 30, 2006. In a final Office Action 
dated September 3, 2009, objections were raised with respect to the drawings, while claims 1- 
20, 22 and 23 were rejected as obvious. By way of this amendment, claims 1 and 23 are 
amended, and new claims 24 and 25 are added. Because two total claims are added hereby 
and three independent claims are pending, this response is accompanied by the requisite fee 
of $104.00 for the net addition of two total claims. It is believed that no additional fees are 
due for the consideration of this paper. However, if additional fees are due, the 
Commissioner is authorized to charge such fees to deposit account number 50-3629. 
Reconsideration and allowance of the pending claims is respectfully requested. 

Response to Drawing Objections 

The Office action reasserts that Applicants have failed to provide Figs. 1-3 that are 
referenced in the written description of the application. It is unclear why this assertion is 
being made as Figs. 1-3 of the application are included in the published version of the present 
application at drawing sheets 1 of 2 and 2 of 2 of U.S. Pat. Appl. Publ. No. 2007/0239465, 
published October 11, 2007. However, in the interest of expediting prosecution of the 
present application, Applicants respectfully submit herewith a Resubmission of Formal 
Drawings including Figs. 1-3 as referenced in the application and described in full at 
paragraphs [0051]-[0089] of the published application. Further support for the drawings is 
provided by Figs. 1-3 and the accompanying text of the parent PCT application to which 
priority is claimed and which is expressly incorporated by reference in the Preliminary 
Amended filed with the present application on May 30, 2006. In view of the submission of 
the drawings, Applicants respectfully request entry of the drawings in this case and 
withdrawal of the objection to the claims. 

Response to Rejections under 35 U.S.C. § 103(a) 

Turning to the prior art rejections, claims 1-3, 13, 15-19 and 23 are rejected under 35 
USC §103 as being obvious over Squire et al. (U.S. Patent No. 5,917,407) in view of Chase 
et al. (U.S. Pat. Appl. Publ. No. 2003/0034873). However, the claims have been amended to 
include additional elements lacking in the cited art and thus the obviousness rejection must be 
withdrawn. To support an obviousness rejection, MPEP §2143.03 requires "all words of a 
claim to be considered" and MPEP § 2141.02 requires consideration of the "[claimed] 
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invention and prior art as a whole." Further, the Board of Patent Appeal and Interferences 
recently confirmed that a proper, post-KSR obviousness determination still requires the Office 
make "a searching comparison of the claimed invention - including all its limitations - with 
the teaching of the prior art." See, In re Wada and Murphy, Appeal 2007-3733, citing In re 
Ochiai, 71 F.3d 1565, 1572 (Fed. Cir. 1995) (emphasis in original). See also, In re Royka, 
490 F.2d 981, 180 USPQ 580 (CCPA 1974) (to establish a prima facie obviousness of a 
claimed invention, all the claim features must be taught or suggested by the prior art). Thus, 
it remains well-settled law that an obviousness rejection requires at least a suggestion of all 
of the claim elements. 

As illustrated on Figures 1 and 2 of the application below, the method claimed in 
claim 1 is an automatic rental method which uses a system comprising the following entities: 

bicycles 1, 

locking stations 9 on which the bicycles 1 are locked before they are rented 
and on which said bicycles are locked again after being rented, 

interactive terminals 2, each controlling several locking stations 9 and 
enabling a user to rent a bicycle (each interactive terminal 2 and the associated 
locking stations 9 thus constitute a bicycle rental station or bicycle rental), 

a rental management server 11 which communicates with the interactive 
terminals 2 of the system, and 

a money server 10 which also communicates with the interactive terminals 2 
of the system. 
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Automatic rental systems for bicycles may have several way of operation, according 
to the type of user: 

some users are regular users, registered in advance in the system and having, for 
example, a dedicated access card, and 

other users are temporary users, for example tourists or other persons staying for a 
short time in a town, or inhabitants of the town who are not familiar with the bicycle 
rental system. 

The claimed method relates to the operation of the system in the second case, i.e. for 
temporary users. More particularly, the claimed method relates to an operation in three 
steps: 

(a) An initial, temporary subscription step: during this initial step, the user has 
a payment card read by an interactive terminal 2 of the system, which 
interactive terminal communicates with the money server 10 for generating a 
debit authorization of a certain maximum amount and valid for a certain 
period, and then an authorization identifier which identifies this 
authorization, is memorized in the rental management server. 



Interactive terminal 


It should be noted that during this initial temporary subscription step, the 
system does not memorize personal data from the card of the user, but the 
money server generates a debit authorization identifier which can thus be 
anonymized (only the money server can then connect this identifier to the 
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user). This appears in the claim by the fact that the authorization identifier 
identifies the authorization and thus does not identify the user (i.e. there is 
no objective relation between this identifier and the user) and by the fact that 
the authorization identifier is generated by the money server (which 
enables the protection of sensitive personal data in the money server, which 
may generally be highly protected and highly controlled by strong legislation). 

(b) One or several rental steps in which the user gives an ID code depending 
upon the authorization identifier (the ID code may be the same as the 
authorization identifier in some embodiments), then the rental management 
server 11 checks the ID code, authorizes or not the bicycle rental and 
increments a rental account. 

(c) A final debit step in which the rental management server 1 1 has the payment 
card debited by the money server 10, within the limit of the authorized amount 
and before the end of the validity period of the debit authorization. The debit 
is a function of the bicycle rentals (for instance, the debited amount depends 
upon the rental times and possibly of a deposit amount if the rented bicycle 
has not been given back). 

The claimed method has in particular the following advantages: 

i. Easy access to the service for the temporary users: 

The claimed method enables a particularly easy temporary use of the bicycles, 
since the access to the system for a limited period of time (irrespective of the 
number of rentals occurring in this period) only requires that the temporary 
user has his payment card read one single time by an interactive terminal 2 
of the system, on any one of the bicycle rental stations or areas of the 
system. Thanks to this easy access, the automatic bicycle rental system can 
meet needs which were not previously met and which represent approximately 
50% of the total needs for bicycle rentals. Thus, the claimed invention enables 
double the use of rented bicycles, compared to previous automatic bicycle 
rental methods. 
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ii. User safety: 

The claimed method has also the advantage of being safe for the user, since it 
does not require registering personal data of the user by the operator of the 
rental system. Such personal data can be retained by the money server, which 
is highly secured and may be subject to very strict legislation for avoiding any 
unsuitable disclosure of the personal data of the user. 

iii. Operator safety: 

The claimed method also enables the operator of the system to protect himself 
against fraud and in particular against theft of the rented bicycles: 

- since the money server can still identify the user, the operator may request 
an investigation from legal authority in case of a theft, so that this authority 
may find the user through the money server; and 

- the operator may determine the amount of the debit authorization at a 
sufficient level so as to cover the price of the bicycle, and thus debit the 
payment card of this amount at the final debit step if the rented bicycle has not 
been given back. 

iv. Savings: 

The claimed method enables to limit the number of bank transactions, and thus 
the transaction costs, since the payment card is not debited at each rental, but 
only once at the end of the authorization period. This enables substantial 
savings at the scale of a town, known that the average number of rentals per 
temporary user is around 2 to 2.5 bicycle rentals per day in towns such as 
Paris, France. 

Squire et al discloses an automatic bicycle rental system which includes, as shown 
hereafter (the coloring/shading added on the figures of Squire et al. correspond respectively 
to those already used above for similar elements of the present invention): 

bicycles 104, 

interactive terminals 106 ("control component"), 

a rack 116 of locking stations which are controlled by interactive terminal 
106 and on which the bicycles 104 can be locked, 
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a control center 210 connected to several interactive terminals 106, and 
a credit verification center 212. 
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Squire et al. discloses a rental method without any subscription, comprising an 
initial renting step and a later debit step. 

(a) Initial renting step: As indicated in particular at col. 10, line 56 to col. 11, 

line 15, the user inserts initially a payment card in a card reader 205 belonging 
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to the interactive terminal 106. The interactive terminal 106 (more particularly 
the computer 206 thereof) reads the card number and opens a customer file in 
its memory. This customer file is identified by the number of the payment 
card, i.e. by a personal data of the user. The interactive terminal 106 
communicates then with the card verification center 212 to check whether the 
card is valid and whether sufficient credit remains on the card (col. 11, lines 5 
- 8 of Squire et al.). If the card verification center 212 authorizes the 
transaction, the user is invited to give the number of a bicycle locking station 
in the rack 116 (col. 11, lines 16 - 18). The interactive terminal 106 then 
unlocks the bicycle of this locking station (col. 1 1, lines 24 - 34) and the user 
can use this bicycle. 

(b) Debiting step: When the user stops using the rented bicycle, he or she returns 
the bicycle to the bicycle renting station, as follows: 

the user must insert again his / her payment card in the card reader of 
the interactive terminal 106, so that the computer 206 of this 
interactive terminal retrieves the customer file from the memory, using 
the card number (col. 11, lines 38 - 43), and 

the interactive terminal 106 then indicates to the user in which bay 124 
to re-lock the bicycle on the rack 116 (col. 11, lines 45 - 49). 

When the rented bicycle has been returned to the renting station and the payment card 
has been read again by the interactive terminal 1 06, the amount of the rent is debited from the 
card of the user (col. 12, lines 18 - 20). The payment card of the user is thus debited each 
time a bicycle is rented. 

It should be noted that Squire et al. teaches that multiple rental stations 101 can be 
interconnected to form a system controlled by a control center 210. The task of the control 
center 210 is to centralize data from the interactive terminals 106, such as rental charges, 
frequency of the rentals, total usage factor and the like, according to the location of the rental 
station 101 (col. 12, lines 30 - 37). The control center 210 is thus used to: 

enable the operator to monitor the rentals and if necessary to add bicycles in 
the rental stations 101 which would lack bicycles (col. 12, lines 37-41 and 
col. 12, lines 46 - 50), 
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track the movements of bicycles between the various rental stations (col. 12, 
lines 41 - 46), and 

inform full or empty rental stations of the nearest rental station having empty 
space or having bicycles available (col. 12, lines 50 - 56). 

Squire et al. further indicates, without any further precision, that interconnecting the 
rental stations 101 enables a user to rent a bicycle 104 at one rental station and to return it at 
another rental station (col. 12, lines 56 - 58). 

The method according to claim 1 distinguishes over Squire et al. by the following 
features: 

(1) The method of claim 1 includes an initial subscription step (a) which is distinct 

and independent from the rental steps (b). This feature enables a user to successively 
rent several bicycles with the same ID code obtained at the initial step (a). To the 

contrary, Squire et al. teaches that reading the payment card of the user is part of the rental 
process which has to be repeated each time the user rents a new bicycle. There is no initial 
subscription step as the claimed step (a), enabling multiple subsequent rentals. At paragraph 
8 of the Office Action, the Examiner points out that multiple rentals were not positively 
claimed in claim 1 and states that a recitation of how the claimed method is intended to be 
employed is not a distinctive feature. As amended, Claim 1 now states that the authorization 
identifier is "enabling several subsequent rental steps within said maximum value and said 
limited period". 

Further, it is unquestioned that the claimed method has an initial subscription step 
that is distinct and independent from any subsequent rental step. 

In the claimed method, the user can carry out step (a) and then defer the 
rental of a bicycle (step (b)) until any time during the claimed "limited 
period;" and 

several rentals are made possible because the only limits are the authorized 
debit amount and the authorized period. 

Consequently, claim 1 enables multiple rentals (of course, the user is free to rent 
only once), contrary to Squire et al. where each rental has to begin with a card reading and an 
authorization of the money server. 
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(2) The claimed method makes use of a rental management server and of a money 
server, whereas Squire et al. does not teach that control center 210 and credit verification 
center 212 be servers. At paragraph 8 of the Office Action, the Examiner indicates that the 
use of such servers fails to affect the method steps of claim 1 . However, the method steps (a), 
(b) and (c) of claim 1 require an automated and fast operation which could not be possible 
without the use of servers. 

(3) According to claim 1, the money server 10 sends a debit authorization of a 
certain maximum amount and valid for a certain period which enables the user to make 
several rentals within the maximum debited value and the authorized period without having 
to reread the payment card. This feature is not taught by Squire et al, and Squire et al. does 
not enable successively renting several bicycles from a single reading of the user's card. At 
paragraph 8 of the Office Action, the Examiner states that Squire et al. disclose at col. 9, line 
55 - col. 10 line 13, an authorization to debit a deposit on the user card, which would imply 
an authorization payment of a certain amount. Applicant respectfully disagrees. This passage 
of Squire et al. ("the rental and any deposit required for the rental is charged to the card''') 
implies that the rental and the deposit are actually charged to the card at the rental step, 
which is very different from the claimed debit authorization which is not charged to the card . 
In the claimed method, the card is automatically charged at the end of the validity period 
(step (c)), not at step (a). In any case, the passage mentioned by the Examiner cannot be 
interpreted as meaning that a debit authorization for a deposit is given at the beginning of the 
rental step, since there is no support for such interpretation except hindsight. Further, the 
possibility of several rentals based on a single card reading is excluded in Squire et al. 

(4) In step (a) of claim 1 , one memorizes a debit authorization identifier generated 
by the money server, not a personal identifier of the user, so that the operator of the rental 
system has no access to personal data of the user, which is beneficial for the user in terms of 
safety. To the contrary, in Squire et al., each transaction is identified by the number of the 
payment card of the user, i.e. by personal data of the user. A card ID cannot be considered 
as being the claimed debit authorization ID (i.e. a transaction ID), since the same card can be 
used for several transactions and therefore the card ID cannot be considered as a transaction 
ID. 

At paragraph 8 of the Office Action, the Examiner states that claim 1 is not 
limited to an authorization identifier which would identify the authorization only, not the 
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user. Applicant respectfully disagrees. As a matter of fact, the claimed debit authorization ID 
cannot be considered as being personal data since the personal data can be limited to the 
money server in the claimed method and the ID code received by the user can be transmitted 
to another user, so that the system run by the rental operator has no information about the 
actual user. In any case, Squire et al. does not teach any authorization ID which is allocated 
and transmitted by the money server as claimed, which is the feature enabling protection of 
the user's privacy in the claimed method as explained above in the discussion of user safety. 

(5) According to claim 1, the debit authorization identifier is memorized in the 
rental management server 11 at step (a), whereas in Squire et al, the customer file is 
memorized in the interactive terminal 106 which read the payment card. At paragraph 8 of 
the Office Action, the Examiner asserts that storing the debit authorization identifier in the 
rental management server does not affect the claimed method in a manipulative sense. 
Applicant respectfully disagrees. Storing the debit authorization identifier in the rental 
management server enables later centralized and quick automated rental management, even in 
cases where the bicycles are rented at one station and returned at another one, since all 
stations can easily and directly communicate with the rental management server at step (b), 
and the server can easily and automatically communicate with the money server to charge the 
user card at step (c) at the end of the limited period. 

(6) According to claim 1, at each rental step (b), the user gives an ID code linked to 
the debit authorization identifier. This substep does not exist in Squire et al., since the 
rental step begins by reading the payment card in the reference. 

(7) According to claim 1, at each rental step (b), the ID code given by the user is 
checked by the rental management server 11, which authorizes the rental or not and 
increments a rental account. In Squire et al., the control center does not check any code or 
authorize any rental or increment any rental account of the user. Therefore, this centralized 
management in the claimed method enables an easy operation of a system including a 
plurality of stations, whereas in Squire et al., all rental management operations are made in 
the interactive terminals 106, which is notably complicated when a user takes a bicycle at one 
station and returns it at another station. As a matter of fact, the method of Squire et al. implies 
determining which station is the initial station, and then having the two stations communicate 
together to retrieve the customer file at the second station. 
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(8) According to claim 1, during the debiting step (c), the payment card is debited by 

the rental management server, using the debit authorization identifier. This debiting step 
can therefore be automatic and does not require any further card reading, whereas in Squire et 
al, the card is debited by the interactive terminal 106 of the station at which the user 
returns the bicycle. This debiting step is made using the card number, therefore requiring a 
further card reading. Therefore: 

In Squire et al., the payment card is debited each time the user returns a 
bicycle, which is costly in transaction costs and inconvenient for the user; and 

this debiting step implies complex data exchanges between interactive 
terminals 106 of the stations 101 as soon as the user takes the bicycle at one 
station and returns it at another station. In such a case, payment of the rental 
implies determining which station is the initial station and then having the two 
stations communicate together to retrieve the customer file at the second 
station before communicating with the money server. 

At paragraph 8 of the Office Action, the Examiner asserts that Squire et al. would 
disclose at col. 9, line 55 - col. 10 line 13, an authorization to debit a deposit on the user card, 
which would imply an authorization payment of a certain amount given at "step (a)". 
Applicant respectfully disagrees. First of all, step (a) does not exist in Squire et al, as 
already explained above. Further, this passage of Squire et al. ("the rental and any deposit 
required for the rental is charged to the card") implies that the rental and the deposit are 
actually charged to the card at the beginning of the rental step, which is very different from 
the claimed debit step (c) which is carried out after the rental steps (b). 

The Chase et al. publication fails to disclose the elements missing from Squire et al., 
and therefore does not provide a sufficient basis for establishing a prima facie case of 
obviousness. Chase et al discloses a method for renting cars wherein a "zipcar.com server" 
manages a database of cars and registered users. In this database, each registered user has a 
personal ID (paragraph [0034]). Chase et al teaches that the registered user can reserve a car 
at a certain location for a certain period (paragraphs [0018] and [0053]). When the user takes 
the reserved car, he / she enters a user ID for checking his identity (§50) and the zipcar.com 
server then enables the rental. 
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First of all, a person skilled in the art would not have tried to find an efficient solution 
to the problem of temporary subscriptions in Chase et al., since Chase et al. requires the users 
to be registered in advance in the database of the zipcar.com server, which is useless for the 
tourist which would like to rent a car through the automatic system of Chase et al. "on the 
spot", without being previously known to the system. In such a case, the tourist would have 
to go through the complete and cumbersome process of becoming a long term registered user, 
which is even more cumbersome and longer than renting a car through a usual renter. For 
this first reason, Chase et al. could not have rendered claim 1 obvious in combination with 
Squire et al. because the person skilled in the art would not have combined those two 
documents. 

Even supposing that the person skilled in the art would have tried such combination 
(which is denied), such combination would not have led the person skilled in the art to the 
claimed invention. Chase et al. does not provide the teaching missing from Squire et al. of 
the differences (1) - (6) and (8) between the limitations of claim 1 and the disclosure of 
Squire et al.: 

(1) Chase et al. discloses no initial subscription step (a) which would be distinct 

and independent from the rental steps (b) and which would enable several rentals. In 
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Chase et al., the initial step is a reservation step without any card reading and this 
reservation step is not independent from the later rental step. To the contrary, this reservation 
step is connected to one single possible rental, and the same reservation cannot be used for 
successive rentals at will (which would be inconsistent with the very notion of "reservation"). 

(2) The use of a money server is not taught by Chase et al. At paragraph 8 of the 
Office Action, the Examiner indicates that the use of such servers fails to affect the method 
steps of claim 1 . However, the method steps (a), (b) and (c) of claim 1 require an automated 
and fast operation which could not be possible without the use of servers. 

(3) Chase et al. does not teach that the money server sends a debit authorization of a 
certain maximum amount and valid for a certain period, which in the claimed method 
enables then to make several rentals within the maximum amount and the authorized period, 
without having to read again the payment card. This feature is not taught by Chase et al., and 
Chase et al. does not enable successively renting several bicycles from a single reading of the 
user card. 

At paragraph 8 of the Office Action, the Examiner states that Chase et al. would teach 
reserving a vehicle for a limited period of time, so that it would be obvious to reserve a 
bicycle for a limited period of time in Squire et al. Applicant respectfully submits that the 
Examiner's assertion is not related to a claimed feature. Claim 1 does not recite that a bicycle 
is reserved for a limited period of time: claim 1 recites that the debit authorization is valid for 
a certain period of time, which is absent from Chase et al. 

(4) Chase et al. does not teach that the rental management server memorizes a debit 
authorization identifier generated by the money server. In Chase et al., the user ID is 
memorized in advance, but this user ID is not a debit authorization ID. 

Further, the operator of the rental system in Chase et al. has access to personal data of 

the user, contrary to the claimed method which enables to protect such personal data in the 

money server. At paragraph 8 of the Office Action, the Examiner states that claim 1 is not 

limited to an authorization identifier which would identify the authorization only, not the 

user. Applicant respectfully disagrees. As a matter of fact, the claimed debit authorization ID 

cannot be considered as being a personal data since the personal data can be limited to the 

money server in the claimed method and the ID code received by the user can be transmitted 

to another user, so that the system run by the rental operator has no information about the 

actual user. In any case, Squire et al. does not teach any authorization ID which is allocated 
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and transmitted by the money server as claimed, which is the feature enabling protection of 
the user's privacy in the claimed method as explained above in the discussion of user safety. 

Furthermore, the Examiner asserts that the user ID could be the claimed authorization 
ID, but a debit authorization ID is a code that enables a third party to charge the user card in 
the money server without any further approval of the user. This definition is of course not 
applicable to the user ID of Chase et al. (Applicants would be interested to hear whether 
anyone ever succeeded in charging a payment card belonging to another person in a money 
server just by knowing the identity of said other person.). 

(5) Since Chase et al. does not teach any debit authorization identifier, this document 
cannot teach that the debit authorization identifier is memorized in the rental management 
server 11 as claimed. As noted above, storing the debit authorization identifier in the rental 
management server does affect the claimed method in a manipulative sense. 

(6) Since Chase et al. does not teach any debit authorization identifier, this document 
cannot teach that the user gives an ID code linked to the debit authorization identifier. 
The driver specific code of Chase et al. is linked to the driver, not to any debit authorization. 

(8) Chase et al. does not teach that the user's payment card is debited by the rental 
management server, using the debit authorization identifier. 

Because neither the Squire et al. patent nor the Chase et al. publication teach or 
suggest any of these elements, if follows that the proposed combination of the references 
does not render obvious either independent claim 1 or claims 2, 3, 13, 15-19 depending there 
from. 

The system of claim 23 also differentiates over Squire et al. at least by the following 
features: 

(l 1 ) Claim 23 mentions a rental management server and a money server, whereas 

Squire et al. does not disclose that control center 210 and credit verification center 212 be 
servers. 

(2') According to claim 23, the interactive terminals include means for obtaining a 

debit authorization of a certain maximum value and valid for a limited period on the 

payment card, this authorization being issued by the money server and enabling multiple 
rentals, and said authorization being identified by an authorization identifier. This feature 
is absent from Squire et al., where the interactive terminal receives no authorization 
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temporary debit authorization and no authorization identifier from the credit verification 
center 211. 

(3') According to claim 23, the rental management server includes means for 

memorizing said authorization identifier. To the contrary, in Squire et al, each transaction is 
identified by the payment card number and not by any ID identifying the authorization 
(i.e. the transaction), so that the operator of the system of Squire et al. possesses sensitive 
data belonging to the user. Further, Squire et al. provides that the client file (with the card 
number) is memorized in the interactive terminal 106 used for the rental, not in the control 
center 210. 

(4') According to claim 23, the rental management server includes means for 

determining whether an ID code given by the user corresponds to said authorization 
identifier, so as to authorize a rental or not and for incrementing a rental account at each 
rental. These features cannot be found in Squire et al., since in Squire et al., any rental begins 
with reading the payment card instead of beginning by giving the ID code corresponding to a 
debit authorization identifier previously received from the money server. Further, the 
authorization of rental is given directly by the interactive terminal 106 of Squire et al. and not 
by the control center 210, and Squire et al. does not provide for any rental account. 

(5') According to claim 23, the rental management server is adapted to communicate 
to the money server, the authorization identifier and an amount to be charged on the payment 
card account, said amount being a function of the rentals made and being at most equal to 
said maximum value. In Squire et al., the payment card is charged by the interactive 
terminal 106 of the rental station 101 where the user returns the rented bicycle, and this debit 
is made after reading the payment card again and not automatically from a payment 
authorization ID. 

A person skilled in the art would not have looked to Chase et al. with reference to 
Squire et al. and combined the references as proposed in the Office action. First of all, a 
person skilled in the art would not have tried to find an efficient solution to the problem of 
temporary subscriptions in Chase et al, since Chase et al. requires the users to be registered 
in advance in the database of the zipcar.com server. Such registration is useless for the 
tourist which would like to rent a car through the automatic system of Chase et al. "on the 
spot," without being previously known to the system. In such a case, the tourist would have 
to go through the complete and cumbersome process of becoming a long term registered user, 
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which is even more cumbersome and longer than renting a car through a usual renter. For at 
least this first reason, Chase et al. could not have rendered claim 23 obvious in combination 
with Squire et al. because the person skilled in the art would not have combined the two 
documents. 

Even assuming that a person skilled in the art would have tried such combination 
(which is denied), such combination would not have led the person skilled in the art to the 
claimed invention of claim 23. Chase et al. would not have provided the teaching missing 
from Squire et al. of the differences (1') - (5') and (8) between claim 23 and Squire et al. 
discussed above. 

(1') Chase et al. does not disclose any money server. 

(2') In Chase et al, the base station does not include means for obtaining a debit 

authorization of a certain maximum value and valid for a limited period with the 
payment card, this authorization being issued by the money server and enabling multiple 
rentals, and said authorization being identified by an authorization identifier. No debit 
authorization is provided in Chase et al., no card reading is provided at the reservation step, 
and multiple rentals are not available from a single reservation. 

(3') In Chase et al., the rental management server (Zipcar.com server) does not 

include means for memorizing any authorization identifier. In Chase et al., the user ID is 
memorized in advance by the Zipcar.com server, but this user ID is not a debit authorization 
ID. 

(4') In Chase et al., the rental management server does not include means for 

determining whether an ID code given by the user corresponds to said authorization 
identifier, so as to authorize a rental or not and for incrementing a rental account at each 
rental. Since Chase et al. does not teach any debit authorization identifier, this document 
cannot teach that the user gives an ID code linked to the debit authorization identifier. The 
driver specific code of Chase et al. is linked to the driver, not to any debit authorization. 
Further, no rental account is incremented at each rental in Chase et al. 

(5') Chase et al. does not provide that the rental management server is adapted to 
communicate to the money server, the authorization identifier and an amount to be charged 
on the payment card account, said amount being a function of the rentals made and being at 
most equal to said maximum value obtained at the debit authorization. 
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Therefore, the subject matter of claim 23 is not obvious over Squire et al. in view of 
Chase et al. In light of all the foregoing the claimed subject matter of amended claims 1-3, 
13, 15-19 and 23 would not have been made obvious by a combination of Squire et al and 
Chase et al., and such obviousness rejection should be withdrawn and should not be extended 
to new claims 24 and 25 for similar reasons. 

Claims 4-12, 14, 20 and 22 are also rejected as obvious based on Squire et al. and 
Chase et al. in further view of Laval et al., Tung and Meunier. However, Laval et al., Tung 
and Meunier are only cited to purportedly show dependent features and are even further 
removed from the claimed subject matter than the main references of Squire et al. and Chase 
et al. In no way do they supply all the missing elements identified above. In light of this, 
applicants respectfully submit that such obviousness rejections should be withdrawn as well. 

CONCLUSION 

For at least the foregoing reasons, reconsideration and withdrawal of the rejection of 
the claims and allowance of the currently pending claims are respectfully requested. Should 
the Examiner wish to discuss the foregoing or any matter of form in an effort to advance this 
application toward allowance, Examiner Long is urged to telephone the undersigned at the 
indicated number. 

Dated: March 3, 2010 Respectfully submitted, 

By /Scott E. Baxendale #41.605/ 

Scott E. Baxendale 

Registration No.: 41,605 
MILLER, MATTHIAS & HULL 
One North Franklin Street 
Suite 2350 

Chicago, Illinois 60606 
(312) 977-9969 
Attorney for Applicant 
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